|
FX2
Introduction/Overview |
|
EZ-USB FX2 offers a highly flexible and configurable Full Speed and High Speed USB peripheral function that's designed
to achieve the maximum USB 2.0 High Speed bandwidth. FX2 accomplishes this through its auto-transfer and peripheral interface architecture.
The GPIF (General Programmable InterFace) engine is one of the vehicles for the auto-transfer architecture, and is used to gluelessly move data
between FX2, your external slave device, and the USB host. The following sections briefly touch upon the silicon architecture and implementation
of FX2, and will lay the groundwork for understanding GPIF concepts discussed later on.
|
|
Why an Auto-Transfer Architecture? |
|
In order to achieve the maximum USB 2.0 High Speed bandwidth, it was proven that the CPU (in this case an enhanced 8051 core)
should never be directly involved in moving the payload data from the external slave device to the USB host (and vice versa). The CPU would clearly be
the largest bottleneck in a High Speed design. So instead an Auto-Transfer mode was invented, whereby the payload data is "auto-committed" from the USB
host to the external slave device and likewise in the other direction. The GPIF engine uses this Auto-Transfer mode to move data to and from the external
slave device. Figures 1 and 2 show a system level view of the data flow for both the IN and OUT directions. |
|
|
|
|
|
Silicon features that facilitate the Auto-Transfer Architecture |
|
Endpoint FIFOs |
|
|
|
|
The CPU in FX2 has a minor role in the Auto-Transfer architecture as it does not participate in moving the payload data, but it does play a very important role nonetheless. The CPU configures and defines how the physical interface operates, sets up the endpoint configurations, triggers GPIF transfers, and can be allowed to manually commit the data packets to either the USB or peripheral domain. It can also monitor the status of the external world, thus giving it the capability of regulating GPIF transfers. |
|
|